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ABSTRACT 


Boeing  Phantom  Works  collaborated  with  Air  Force  Research  Laboratory  (AFRL)  researchers  at 
the  Aerospace  Vehicles  Technology  Assessment  and  Simulation  (AVTAS)  Laboratory  and  with 
Northrop  Grumman  to  conduct  the  Open  Control  Platform  (OCP)  Hardware-In-The-Loop 
(HITL)  project  sponsored  by  the  DARPA  Software  Enabled  Control  (SEC)  Program.  The  pur¬ 
pose  of  this  project  is  to  develop  the  capability  to  be  an  OCP  test-bed  and  to  evaluate  the  OCP 
controls  and  simulation  environment  for  a  specific  test  case.  The  OCP,  developed  by  Boeing, 
provides  an  open,  middleware-enabled  software  framework  and  development  platform  for  devel¬ 
opers  of  distributed  and  embedded  software  applications.  The  middleware  isolates  the  program¬ 
mer  from  the  details  of  the  operating  system  and  provides  a  mechanism  for  communication  with 
other  OCP  software  components.  A  Traffic  Collision  Avoidance  System  (TCAS)  was  chosen  as 
a  representative  flight  controls  application  to  exercise  OCP.  The  programmatic  approach  taken 
by  the  OCP-HITL  project  was  a  series  of  simulation  experiments  with  increasing  complexity. 
The  first  simulation  was  an  “all  software”  simulation,  conducted  in  August  2002.  A  portion  of 
the  “all  software  simulation”  was  then  migrated  to  a  VME  based  system  running  VxWorks.  A 
readiness  review  of  the  HITL  simulation  was  conducted  in  March  2003,  followed  by  a  successful 
HITL  simulation  demonstration  on  13  May  2003.  The  demonstration  tested  a  2-ship  non-co- 
operating  scenario,  a  2-ship  cooperating  scenario,  and  a  pilot-in-the-loop  scenario.  Future  test¬ 
ing,  planned  for  May  2004,  includes  formation  flight  and  fault  injection  scenarios. 


INTRODUCTION 

The  OCP  is  a  software  infrastructure  being  developed  by  the  Boeing  Corporation  sponsored  by 
the  DARPA  SEC  Program.  It  is  intended  to  enhance  the  ability  to  develop  and  test  control 


algorithms  which  will  eventually  execute  in  embedded  software  within  Uninhabited  Air  Vehicles 
(UAVs).  The  OCP  supports  distributed  computing  and  communication  allowing  heterogeneous 
components  to  interoperate  across  platforms  and  network  protocols  while  dealing  with  tight  con¬ 
straints  on  bandwidth,  response  time,  and  reliability.  By  using  OCP,  control  engineers  can  con¬ 
centrate  on  the  controls  problem  at  hand  without  having  to  worry  about  the  details  of  component 
connectivity.  The  “middleware”  design  of  OCP  isolates  the  operating  system  and  the  underlying 
hardware  allowing  development  and  testing  to  take  place  on  a  system  architecture  different  from 
the  final  target.  The  well-defined  interfaces  inherent  with  an  OCP  design  facilitate  efficient  par¬ 
titioned  software  development  and  insure  a  relatively  painless  final  integration. 

The  HITL  simulation  using  OCP  was  designed  to  evaluate  some  of  the  key  OCP  principles: 

1.)  Architecture  isolation/independence  -  The  simulation  incorporated  three  different  system  ar¬ 
chitectures;  Windows2K  on  a  PC,  Linux  on  a  PC,  and  VxWorks  on  a  PowerPC;  2.)  Ease  of  port¬ 
ing  -  The  simulation  was  initially  built  and  tested  as  an  “all  software”  simulation.  The  process 
initially  running  on  the  Windows  2K  platform  was  migrated  to  the  HITL;  and  3.)  Partitioned 
software  development  -  Three  teams  were  involved  in  the  development  of  the  simulation.  Our 
Boeing  team  provided  OCP  support  and  in  particular  provided  key  support  on  the  integration  of 
the  PowerPC  into  AVTAS’s  architecture.  The  Northrop  team  developed  all  of  the  components 
associated  with  the  Traffic  Alert  and  Collision  Avoidance  System  (TCAS)  algorithms  and  the 
aircraft  models  utilized  in  the  simulation.  The  AVTAS  team  built  the  OCP  components  neces¬ 
sary  to  interface  the  facility’s  Infinity  Cube  Simulator  to  the  OCP  HITL  simulation. 
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This  report  will  first  provide  an  introduction  to  OCP  followed  by  a  discussion  on  the  models  and 
the  TCAS  algorithms  employed  in  the  simulation.  The  simulation  architecture  and  scenarios  will 
then  be  presented.  The  report  will  conclude  with  results  of  the  testing  to  date  and  a  discussion  on 
transition  and  potential  future  work  with  OCP  and  vehicle  simulation. 

OCP  INTRODUCTION 

The  OCP  provides  an  open,  middleware-enabled  software  framework  and  development  platform 
for  developers  of  distributed  and  embedded  software  applications.  The  middleware  layer  of  the 
OCP  provides  the  software  layer  isolating  the  application  software  from  the  underlying  compute 
platform.  It  provides  services  for  controlling  the  execution  and  scheduling  of  software  compo¬ 
nents,  mediating  inter-component  communication,  and  enabling  distribution  of  application  com¬ 
ponents  onto  a  target  system.  The  OCP  includes  innovative  scheduling  techniques,  adaptive  re¬ 
source  management,  and  support  for  dynamic  reconfiguration. 

The  OCP  is  being  developed  by  the  Embedded  Systems  Research  Team  within  Boeing  Phantom 
Works.  Assisting  Boeing  in  these  efforts  are  the  Georgia  Institute  of  Technology,  Honeywell 
Labs,  and  the  University  of  California,  Berkeley.  The  OCP  is  being  delivered  to  a  host  of  uni¬ 
versity  and  industrial  researchers  who  are  participating  in  the  DARPA  SEC  Program. 

OCP  OVERVIEW  AND  BACKGROUND 

The  OCP  is  composed  of  many  elements,  discussed  in  later  sections,  which  enable  the  rapid  gen¬ 
eration  and  test  of  embedded  and  distributed  software  application  programs.  Included  among 
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these  elements  are: 


1)  a  middleware  software  infrastructure  component, 


2)  a  Controls  API  that  allows  for  tool-based  software  architecture  specification  and  auto¬ 


coding  of  a  software  framework  that  implements  the  specification,  and 


3)  an  integration  with  useful  controls  development  tools,  software  tools,  and  simulation 


tools. 


The  software  infrastructure  component  has  its  heritage  in  the  CORBA  [1]  (Common  Object  Re¬ 
quest  Broker  Architecture)  based,  Boeing-funded  software  initiative  called  Bold  Stroke.  Under 
the  Bold  Stroke  initiative,  CORBA  and  its  attendant  object  technologies  were  leveraged  as  a 
prime  enabler  for  re-use  of  software  components  across  product  lines,  and  for  rapid  re¬ 
implementation  of  existing  solutions  on  changing  and  evolving  computing  hardware  and  operat¬ 
ing  system  platforms  -  primary  considerations  in  achieving  affordable  avionics  software  devel¬ 
opment. 

Boeing,  in  prior  flight  demonstrations  on  multiple  types  of  aircraft,  has  successfully  demon¬ 
strated  application  of  this  CORBA  technology  in  the  domain  of  non-safety  critical  mission  proc¬ 
essing,  which  required  hard  real  time  performance  in  tasks  that  ran  at  rates  up  to  40  Hz.  One  of 
the  goals  of  OCP  is  to  bring  the  advantages  of  object  oriented  programming  and  CORBA  to  the 
domain  of  UAV  multi-level  flight  control.  The  application  of  CORBA  in  this  domain  introduces 
new  challenges  for  the  OCP  that  have  spawned  new  requirements  for  OCP  services.  Challenges 
include:  1)  faster  rates,  2)  the  need  to  ensure  vehicle  stability,  3)  highly  accurate  timing  in  sensor 
processing,  and,  4)  achievement  of  hard  deadlines  at  flight  control  rates.  Candidate  software  in¬ 
frastructure  services  have  been  implemented  in  the  OCP  to  meet  these  challenges. 
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OCP  MIDDLEWARE 


The  middleware  of  the  OCP  can  be  used  to  fuse  embedded  and  distributed  system  application 
software  components  together,  controlling  their  execution  and  communication. 

A  primary  motivating  factor  in  implementing  a  middleware-based  architecture  was  the  promise 
of  isolating  the  application  components  from  the  underlying  platforms.  This  allowed  for  a  more 
cost-effective  path  for  implementing  common  software  components  that  could  be  used  (1)  across 
different  product  lines,  and  (2)  could  be  rehosted  onto  evolving  embedded  computing  platforms. 
Support  for  rapid  re-implementation  of  existing,  tested  designs  onto  evolving  computing  plat¬ 
forms  is  important  for  maintaining  an  effectiveness  advantage  in  currently  fielded  embedded  sys¬ 
tems. 

These  evolving  computing  platforms  are  starting  to  be  dominated  by  commercial  hardware  and 
software  components,  which  have  more  dynamic  lifecycles  than  previous  military  components, 
and  which  create  more  opportunities  for  incorporation  of  computing  advances  into  existing  sys¬ 
tems.  Further,  more  commercial  and  military  flying  platforms  are  experiencing  longer  lifetimes, 
and  the  ability  to  inexpensively  re-host  existing  functional  and  tested  software  on  updated  com¬ 
puting  platforms  is  very  attractive. 

The  embedded  software  framework  of  the  OCP  inherits  the  RT-CORBA  (Real  Time-CORBA) 
based  middleware  of  Bold  Stroke.  The  inherent  advantages  of  a  middleware-based  solution 
within  OCP  should  prove  to  be  an  enabler  for  current  and  future  embedded  and  distributed  soft- 
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ware  developments. 


Use  of  the  CORBA-based  middleware  helps  isolate  application  software  components  from  the 
underlying  hardware  and  operating  systems  in  the  computing  platform.  The  resulting  layered 
architecture  is  illustrated  in  Figure  1. 


Software  Application  I 
Components  1 


OCP  Middleware 
Download 


Open  Systems  Software 
Open  Systems  Hardware 


Figure  1.  OCP  Layered  Architecture 


The  middleware  also  facilitates  distributed  processing  and  inter-component  communications  by 
supporting  CORBA  event-based  communication,  as  illustrated  in  Figure  2. 


Figure  2.  Distributed  Processing  and  Inter-Component  Communications 
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The  ability  of  the  OCP  to  isolate  application  components  from  the  underlying  system  also  can  be 
used  to  enable  efficient  embedded  and  distributed  system  software  development.  For  initial  de¬ 
sign  and  development,  application  code  integrated  with  the  OCP  middleware  can  be  executed  on 
familiar  desktop  systems,  such  as  those  using  Windows  or  Linux  operating  systems.  Certain  lev¬ 
els  of  software  testing  can  take  place  more  conveniently  on  the  desktop.  Then,  the  operating  sys¬ 
tem  and  hardware  isolation  features  of  the  middleware  would  be  instrumental  in  implementing 
the  smooth  transition  of  the  developed  embedded  application  code  to  the  embedded  hardware 
target  —  perhaps  a  target  executing  a  POSIX-compliant  Real-Time  Operating  System  (RTOS), 
such  as  VxWorks  or  QNX.  Isolation  of  the  application  would  result  in  minimal  code  changes 
during  transition  to  the  embedded  target. 

The  middleware  of  OCP  is  being  designed  so  that  it  offers  the  embedded  software  developer  a 
rich  set  of  features  desirable  for  real-time  applications.  These  features  include  dynamic  schedul¬ 
ing;  adaptive  resource  management;  dynamic  reconfiguration;  hybrid  system  mode  switching 
support;  and  convenient  access  to  real-time  triggers. 

Embedded  applications  built  with  the  OCP  middleware  exhibit  a  layered  architecture,  as  shown 
in  Figure  3.  The  bottom  software  layer  shown  is  that  of  the  operating  system  (OS).  The  OCP 
has  been  designed  to  allow  applications  to  be  executable  on  a  variety  of  OSs,  including  desktop 
non-real  time  Windows  and  Linux,  as  well  as  RTOSs,  such  as  VxWorks  and  QNX. 

The  OS  portability  is  enabled  with  the  next  highest  layer,  an  OS-abstraction  layer  implemented 
by  the  open-source  Adaptive  Communications  Environment  (ACE)  software.  ACE  provides 


7 


common  OS  services  to  software  residing  in  the  layers  above  it.  Software  in  these  upper  layers 
can  access  useful  OS  services  with  ACE  calls,  and  ACE  then  translates  the  requests  into  OS- 
specific  requests. 


The  advantages  of  CORBA  are  made  accessible  in  OCP  by  the  next  highest  layer,  the  TAO  (The 
ACE  ORB)  layer.  TAO  and  ACE  are  available  as  open  source  implementations  from  Washing¬ 
ton  University  in  St.  Louis.  TAO  has  been  developed  as  an  ORB  (Object  Request  Broker)  im¬ 
plementation  that  is  portable  across  a  variety  of  underlying  compute  platforms.  TAO  itself  pro¬ 
vides  some  real-time  performance  extensions  to  CORBA. 


Develop  Reusable 
Application  Components 


Develop  Reusable 

Architecture  Framework 

Station 


Airframe 

Radar 

Tgts 

FUR 

Weapons 

Fly-out 

Model 

Infrastructure  Services 


Operating  System 


Board  Support  Package 


Hardware  (CPU,  Memory,  I/O) 


Figure  3.  Layered  Architecture  of  an  OCP-Based  Application 


Above  the  TAO  layer,  the  OCP  middleware  presents  to  the  application  a  rich  set  of  run-time 
services,  many  of  them  based  on  standard  CORBA.  On  top  of  ACE  and  TAO,  some  real-time 
performance  extensions  were  developed  by  Boeing,  under  the  Bold  Stroke  project,  and  utilized 
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in  fighter  aircraft  Mission  Management  embedded  software.  The  OCP  includes  further  real-time 
performance  support  to  handle  the  requirements  of  UAV  control.  Some  of  the  more  important 
services  are  discussed  below. 

CORBA  Services  (Real-Time  Publish  /  Subscribe) 

The  CORBA  event  channel  (EC)  can  be  used  to  route  data  between  software  components  with¬ 
out  resorting  to  parameter  passing  or  global  memory  pools,  both  of  which  are  difficult  to  design 
and  maintain  for  applications  distributed  over  multiple  threads,  processes,  and  processors.  Data 
being  generated  by  a  software  component,  if  it  is  needed  elsewhere  in  a  system,  can  be  published 
over  the  EC.  Other  software  components  in  the  system  which  have  access  to  the  ORB,  and 
which  need  a  particular  input,  can  subscribe  through  the  EC  for  that  input.  The  software  compo¬ 
nent  publishing  the  data  (as  an  output)  and  the  one  or  more  software  components  subscribing  to 
that  data  (as  an  input)  can  reside  anywhere  the  ORB  exists  —  in  the  same  process,  in  different 
processes  within  the  same  computer,  on  different  computers  within  the  same  chassis,  on  different 
computers  at  different  locations  (e.g.,  two  different  vehicles,  or  a  vehicle  and  a  ground  station), 
etc. 

The  CORBA  EC  can  also  be  used  to  trigger  the  execution  of  a  software  component  based  on  pro¬ 
files  of  arriving  inputs.  This  can  be  used  to  relieve  the  software  designer  from  trying  to  derive  a 
correct  cyclic  executive  that  hopefully  satisfies  all  input  data  dependencies  correctly,  which  can 
be  a  daunting  task  for  applications  that  have  large  numbers  of  application  software  components, 
have  multiple  threads,  which  span  more  than  one  process,  and  which  span  more  than  one  proces¬ 


9 


sor. 


OCP  Services  (Resource  Management) 

The  OCP's  Resource  Management  component  provides  a  mechanism  for  controlling  and  making 
better  use  of  compute  resources  in  the  executing  system.  The  OCP  resource  management  com¬ 
ponent  is  an  extension  of  the  Honeywell  Labs  Real  Time  Adaptive  Resource  Management  (RT- 
ARM)  capability.  [2]  With  RT-ARM,  it  is  possible  to  specify  quality  of  service  (QoS)  informa¬ 
tion  about  the  various  software  components  in  the  system.  An  example  QoS  specification  would 
be  the  allowable  rates  of  execution  for  the  proper  operation  of  a  software  component.  While  the 
system  is  in  operation,  the  RT-ARM  functionality  can  adapt  the  scheduling  behavior  of  the  sys¬ 
tem  to  optimize  utilization  of  the  finite  embedded  compute  resources  based  on  the  software  com¬ 
ponents  which  are  currently  active  and  their  QoS  information.  The  resulting  execution  rates  of 
the  components,  as  scheduled  by  the  RT-ARM  capability,  are  communicated  to  the  individual 
software  components  so  that  they  can  then  modify  their  behavior  based  on  their  assigned  rate 
(e.g.,  modify  controller  gains).  RT-ARM  makes  use  of  the  TAO  scheduling  component  [3], 

OCP  Services  (Hybrid  Systems  Mode  Change  Support  --  the  Transition  Service) 

A  hybrid  system  combines  both  continuous  and  discrete  elements.  For  example,  in  a  typical 
flight  controls  system,  the  lower  levels  of  the  architecture  tend  to  be  designed  as  continuous  time 
controllers.  When  moving  to  higher  levels  of  the  architecture,  controllers  tend  to  be  of  the  dis¬ 
crete  supervisory  type.  The  composite  system  can  function  like  a  pseudo-continuous  controller 
able  to  operate  in  one  or  more  distinct  modes. 
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To  help  meet  the  needs  of  this  hybrid  system  philosophy,  system  mode  support  has  been  added 
to  the  OCP  with  the  Transition  Service.  Each  system  mode  can  be  characterized  as  being  made 
up  of  a  specific  profile  of  active  (and  inactive)  software  components,  a  specific  QoS  profile  for 
the  active  components,  and  a  specific  profile  of  input/output  interconnections  between  active 
components.  The  Transition  Service  allows  components  to  identify  the  current  mode  of  the  sys¬ 
tem,  allows  components  to  trigger  mode  changes,  and  allows  for  smooth  mode  transitions  at  ap¬ 
propriate  times  of  system  operation  (e.g.,  after  inner-loop  control  actuator  command  writes). 

Note  also  that  for  each  system  mode,  a  different  profile  of  QoS  parameters  can  be  specified  for  a 
software  component.  This  provides  a  powerful  way  to  allow  use  of  RT-ARM  to  make  the  best 
use  of  available  on-board  resources,  since  some  components  are  more  critical  in  some  system 
modes  and  would  therefore  have  their  more  challenging  resource  demands  reflected  in  their  QoS 
specification  for  those  modes. 

OCP  Services  (Accurate  Time  Triggering  —  the  Timer  Service) 

UAV  flight  control  applications  have  stringent  real-time  constraints  on  operation.  For  example, 
flight  control  sensor  sampling  must  be  accomplished  at  precise  time  intervals,  with  very  little 
frame-to-frame  jitter  and  without  missing  a  sample.  The  Timer  Service  in  the  OCP  provides  a 
way  to  accurately  trigger  a  software  component  based  on  time.  This  is  accomplished  by  provid¬ 
ing  a  convenient  API  linking  a  physical  real-time  clock  on  the  embedded  processor  board  to  a 
software  component  execution  trigger. 
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OCP  Services  (Performance  Optimizations) 

Performance  optimizations  are  being  implemented  in  the  OCP  to  reduce  the  amount  of  time  that 
an  OCP -based  application  spends  in  the  CORBA-based  middleware  layer.  These  optimizations 
include  use  of  light-weight  EC  events,  client-side  caching  to  reduce  the  need  for  data  passing  in  a 
distributed  application,  and  the  ability  to  allow  efficient  protocols  to  be  plugged  into  the  ORB  to 
optimize  data  transfer  speeds  between  specific  components. 

OCP  Controls  API 

As  mentioned  previously,  the  OCP  provides  several  advanced  mechanisms  such  as  adaptive  re¬ 
source  management,  reconfiguration  during  mode  switches,  and  access  to  highly  accurate  timing 
sources  for  component  triggering.  To  help  hide  the  complexity  of  these  features  from  the  con¬ 
trols  designer,  and  to  shield  the  controls  designer  from  C++  or  object  oriented  programming,  the 
OCP  includes  the  Controls  API  —  a  controls  designer  abstraction  layer  above  the  RT  CORBA 
implementation.  This  API  allows  the  designer  to  focus  on  familiar  tools  and  terminology  whilst 
enabling  the  use  of  RT  CORBA  extensions.  This  abstract  layer  was  a  collaborative  Boeing  - 
Georgia  Tech  effort.  The  Controls  API  provides  an  interface  for  managing  OCP  components, 
setting  system  information,  and  controlling  system  execution. 

The  Controls  API  allows  a  software  system  designer  to  lay  out  the  system  graphically  using  the 
popular  Simulink  tool.  Here,  the  designer  specifies  the  software  component  names,  their  inputs 
and  outputs,  and  the  interconnections  with  inputs  and  outputs  of  other  components. 
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This  initial  layout  is  then  decorated  with  additional  information  by  the  system  designer  using  an¬ 
other  graphical  tool  written  in  Java.  Here,  all  other  pertinent  information  about  the  software  sys¬ 
tem  is  specified.  This  other  information  includes  specification  of  system  modes,  the  active  soft¬ 
ware  components  and  their  interconnections  in  each  mode,  QoS  information  for  active  compo¬ 
nents  in  each  mode,  specifications  of  which  components  get  triggered  by  highly  accurate  timers, 
allocations  of  components  to  different  processes,  etc.  The  completed  system  model  is  then  sent  to 
the  final  portion  of  the  Controls  API  for  automatic  generation  of  a  C++  framework  that  will  trig¬ 
ger  software  components  based  on  the  system  model,  that  will  route  inputs  and  outputs  based  on 
the  model,  and  that  will  allow  system  mode  changes  as  specified  in  the  model.  The  autogener¬ 
ated  framework  contains  placeholders  in  the  code  for  the  controls  designer  to  insert  the  code  for 
the  individual  software  components. 


OCP  INTEGRATION  WITH  CONTROLS  DEVELOPMENT  TOOLS  AND  SIMULA¬ 
TION  TOOLS 

The  OCP  provides  integration  with  popular  and  useful  controls  and  software  design,  develop¬ 
ment,  and  testing  tools.  Commercial  tools  like  Microsoft  Visual  C++,  Microsoft  Visual  Debug¬ 
ger,  the  VxWorks  real-time  operating  system,  and  Matlab/Simulink  have  wide  acceptance  in  the 
software  and  controls  communities.  Buildable  and  runnable  examples  delivered  with  the  OCP  to 
illustrate  OCP  features  make  use  of  these  well-supported  commercial  products.  The  debugger 
can  be  used,  for  example,  during  a  running  vehicle  simulation  to  set  breakpoints,  single-step,  and 
perform  other  useful  testing  functions  while  simulation  displays  show  the  dynamic  state  of  the 
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vehicle. 


TCAS  OVERVIEW 


Over  the  course  of  the  HITL  program,  there  has  been  a  growing  emphasis  on  automated  collision 
avoidance.  As  a  result,  logic  from  the  commercially  packaged  software,  TCAS  algorithm,  was 
used  as  a  base  model  for  the  design  of  a  mission  manager  executing  in  an  OCP -based  applica¬ 
tion. 

TEST  SCENARIOS 

Each  vehicle  in  the  HITL  simulation  is  broken  into  eleven  separate  OCP  Components  (Figure  4). 
These  eleven  components  are  then  separated  into  processes  based  on  the  hardware  architecture. 
Since  the  UAV  is  the  only  vehicle  to  be  flown  HITL,  it  is  the  only  one  that  is  separated  into  two 
processes.  One  process  runs  the  controller  on  the  hardware  and  another  updates  the  model  out¬ 
side  of  the  hardware  on  a  WinNT  machine.  All  other  models  are  software  only  and  therefore  run 
on  a  single  process.  This  structure  is  used  as  the  basis  for  the  HITL  programs  five  specified  soft¬ 
ware  test  scenarios.  Each  of  these  scenarios  is  then  executed  under  multiple  collision  course  ap¬ 
proach  angles  (specifically  acute  and  obtuse).  By  running  the  scenario  under  acute  and  obtuse 
relative  heading  conditions,  the  TCAS  algorithm  can  be  tested  under  its  worst-cases:  the  ex¬ 
tremes  of  high  and  low  closure  rates.  The  case  of  low  rate  closure  causes  the  intruder  vehicle  to 
breach  the  separation  threshold  desired  before  the  tau  criteria,  is  breached  and  the  obtuse  case 
causes  the  closure  rate  to  test  the  upper  limits  of  TCAS. 


14 


Pilot 

Command 


Figure  4  -  Block  Diagram  of  OCP  Components 


TEST  RESULTS 

The  first  scenario  successfully  tested  two  vehicles  traveling  on  a  collision  course  and  the  own- 
ship  performs  an  evasive  climb  or  dive  to  avoid  the  intruder.  In  this  scenario  there  is  no  commu¬ 
nication  between  the  vehicles  and  it  is  assumed  that  the  intruder  is  blind  to  what  is  happening. 

In  the  second  scenario  tested,  both  vehicles  are  equipped  with  the  TCAS  mission  manager.  The 
initial  collision  courses  are  the  same  as  the  first  scenario  but  instead  of  the  ownship  taking  on  the 
full  responsibility  of  the  evasive  maneuver,  both  vehicles  react  to  the  possible  collision.  The 
communication  between  the  two  vehicles,  which  was  not  present  in  the  first  scenario,  allows  the 
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vehicles  to  negotiate  a  coordinated  de-confliction  plan  where  one  dives  and  the  other  climbs.  It 
is  noted  that  for  the  initial  instance  in  which  the  vehicles  detect  a  collision,  each  vehicle  attempts 
to  perform  the  entire  de-confliction  alone.  Once  communications  of  the  detection  between  the 
vehicles  begin  and  they  negotiate  a  solution,  each  vehicle  commands  half  of  the  change  in  alti¬ 
tude  required  to  accomplish  the  desired  separation.  This  communication  continues  throughout 
the  maneuver  and  is  updated  constantly  resulting  in  the  more  maneuverable  vehicle  being  re¬ 
quested  to  do  more  of  the  change  in  altitude.  This  is  seen  in  the  time  histories  where  the  more 
agile  generic  fighter  aircraft  is  asked  to  perform  more  of  the  maneuver,  as  time  goes  on  based  on 


its  performance  response. 
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Figure  5  -  Scenario  2  Acute  Time  Histories 
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Scenario  3  adds  a  human-in-the-loop  aspect  to  scenario  2  which  allowed  robustness  testing  of  the 
mission  manager.  (Scenario  3  is  discussed  in  more  detail  in  the  next  section)  The  insertion  of  the 
pilot  allows  us  to  examine  the  reaction  of  the  mission  manager  to  unanticipated  decisions  by  the 
other  vehicle.  The  ownship  has  to  react  to  an  intruder  pilot  overriding  the  negotiated  TCAS 
outer  loop  command. 

The  final  two  scenarios  to  be  completed  are  adding  a  wingman  to  the  ownship  and  fault  injec¬ 
tion.  The  wingman  will  perform  basic  station  keeping  abilities  while  only  communicating  with 
the  ownship.  The  ownship  will  be  the  intermediary  between  the  intruder  and  the  wingman,  who 
will  not  directly  communicate  throughout  the  scenario.  The  final  scenario  is  fault  injection  into 
the  system.  This  scenario  will  test  the  fault  detection  algorithm  being  developed  as  well  as  the 
reconfiguring  of  the  vehicle’s  performance.  The  fault  injector  will  be  another  component  added 
to  the  architecture,  which  will  insert  faults  into  the  model  as  data  is  passed  to  the  fault  detection 
isolation  component. 


Figure  6  -  Fault  Detection  Architecture 
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Pilot-in-the-Loop  HITL  simulation 


The  pilot-in-the-loop  portion  of  the  simulation  (scenario  3)  is  designed  to  evaluate  the  process  of 
integrating  an  OCP  based  simulation  into  the  AVTAS  simulation  architecture  and  to  prepare 
AVTAS  as  a  future  OCP  test  bed. 

The  Infinity  Cube  simulator  is  a  state-of-the-art  fix  based  research  simulator  containing  four  col¬ 
limated  displays  in  a  cube  arrangement,  a  projected  Heads  Up  Display  (HUD),  and  a  29”  monitor 
for  the  Heads  Down  Display  (HDD).  It  contains  a  stick  and  throttle  and  a  set  of  generic  rudder 
pedals.  The  out  the  window  (OTW)  display  is  driven  by  Subrscene,  a  locally  developed  image 
generation  software  package  that  runs  on  PC’s  under  Linux.  Figure  7  shows  the  architecture  em¬ 
ployed  for  the  pilot-in-the-loop  simulation  from  the  OCP  vantage  point 


Figure  7  -  Pilot-In-Loop- Architecture 


A  Windows  2k  platform  runs  OCP  processes  1,  3,  and  5.  Process  1  is  the  ownship  aircraft 

model.  Process  3  contains  both  the  aircraft  model  and  the  controller  for  the  intruder.  Process  5 
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communicates  with  a  Virtual  Battle  space  Management  System  (VBMS)  server  to  update  VBMS 
in  real-time.  One  Linux  platform  is  used  to  host  the  VBMS  display  and  an  associated  CORBA 
based  VBMS  server.  A  second  Linux  platform  runs  OCP  process  4  and  the  infinity  cube  I/O 
process.  Process  4  interfaces  the  rest  of  the  OCP  simulation  to  the  Infinity  Cube.  This  platform 
will  be  discussed  in  more  detail  in  succeeding  paragraphs.  The  final  platform  is  the  HITL  sys¬ 
tem  and  consists  of  a  PowerPC  running  VxWorks.  The  controller  process  for  the  ownship  (Proc¬ 
ess  2)  is  run  on  this  platform.  All  machines  are  connected  to  a  dedicated  Ethernet  network. 
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Figure  8  -  Infinity  Cube  Interface 

Figure  8  shows  in  more  detail  how  the  OCP  portion  of  the  simulation  is  interfaced  to  the  Infinity 
Cube. 


Process  4  consists  of  two  OCP  components.  The  Hands  On  Stick  And  Throttle  (HOTAS)  com¬ 
ponent  is  responsible  for  providing  the  intruder  model  with  the  stick,  throttle,  and  rudder  pedal 
inputs  from  the  infinity  cube.  The  analog  and  digital  signals  from  the  stick,  rudder  pedals,  and 
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the  throttle  are  read  via  a  Keithley  I/O  card  by  the  I/O  process.  This  process  then  places  the  data 
into  SCRAMNet  memory  where  it  is  read  by  the  HOTAS  OCP  component  and  sent  to  the  in¬ 
truder  model  via  standard  OCP  signaling  mechanisms.  The  Subrscene  component  receives 
ownship  and  intruder  state  information  via  OCP  signaling  mechanisms  and  writes  this  informa¬ 
tion  into  SCRAMNet.  A  Visual  Driver  process  running  on  another  Linux  platform  reads  the  state 
information  from  SCRAMNet  and  sends  it  to  Subrscene  via  Ethernet.  Subrscene  is  run  across  4 
Linux  based  platforms  with  one  platform  per  infinity  cube  channel.  The  Subrscene  OCP  compo¬ 
nent  also  sends  the  state  information  to  two  other  Linux  platforms  over  Ethernet.  These  plat¬ 
forms  generate  the  symbology  for  the  HUD  and  the  HDD. 

A  standard  HUD  is  being  used  with  a  modification  to  annunciate  the  condition  when  TCAS  de¬ 
tection  occurs.  An  existing  HDD  was  modified  to  include  a  simple  vertical  and  horizontal  situa¬ 
tion  display  to  facilitate  re-acquiring  the  ownship  aircraft.  The  intruder  model  is  set  up  to  blend 
the  inputs  from  the  stick  and  the  autopilot  for  stick  inputs  below  a  certain  threshold.  When  the 
stick  inputs  exceeded  this  threshold  the  autopilot  is  disengaged.  The  paddle  switch  at  the  base  of 
the  stick  is  used  to  re-engage  the  autopilot. 

The  general  guidelines  for  running  scenario  3  with  pilot-in-the-loop  are  to  allow  the  initial 
avoidance  maneuvers  to  take  place  and  then  try  to  re-acquire  the  ownship  and  force  another  col¬ 
lision  avoidance  situation.  Several  team  members  flew  the  simulation  in  preparation  for  the 
readiness  review.  This  initial  testing  showed  that  all  of  the  interfaces  were  functioning  properly. 
The  cube  display  system  provided  a  compelling  view  of  the  initial  avoidance  maneuvers  per¬ 
formed  by  TCAS.  Stick  and  throttle  inputs  were  verified  to  be  correct  though  some  difficulty 
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was  experienced  in  flying  the  intruder  manually  due  to  the  aero  model  currently  being  employed. 
During  this  initial  checkout  the  ownship  model  was  successfully  re-acquired  on  several  occa¬ 
sions  and  performed  evasive  maneuvers  as  expected. 

FINAL  DEMONSTRATION 

The  final  HITL  demonstration  is  scheduled  for  late  May  2004.  Multiple  vehicles  will  be  simu¬ 
lated,  including  one  vehicle  with  flight  software  executing  in  real-time  on  a  YME-based 
PowerPC  processing  card. 

In  support  of  this  final  demonstration,  Boeing  supported  redesign  of  the  prior  demonstration  ar¬ 
chitecture  to  allow  splitting  the  processing  into  multiple  OCP  instances,  one  for  each  vehicle. 
This  was  done  for  the  convenience  of  those  using  OCP  (Northrop  Grumman,  AFRL),  who 
wanted  to  change  the  number  of  vehicles  in  a  simulation  scenario  more  easily.  Before  this  redes¬ 
ign  activity,  changing  the  number  of  vehicles  in  an  OCP-based  simulation  required  a  multi-step 
process  of  software  rework  with  the  Controls  API  to  implement  the  new  inter-vehicle  software 
connections. 

During  final  demonstration  software  design  and  integration,  Northrop  delivered  to  Boeing  a 
multi-vehicle  simulation  executing  in  a  single  Windows  machine.  Our  Boeing  team  then  ported 
the  software  to  a  distributed  Linux  and  PowerPC/ VxWorks  architecture  on  hardware  at  the  Phan¬ 
tom  Works  site  in  St.  Louis.  The  hardware  layout  at  Boeing  was  similar  to  the  distributed  hard¬ 
ware  architecture  in  the  AFRL/VACD  lab.  Part  of  the  work  that  Boeing  did  to  get  the  UAV 
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software  to  run  in  real  time  included  putting  Northrop  Grumman’s  Kalman  Filter  in  its  own, 
lower-rate  thread,  allowing  all  flight  control  software  elements  to  meet  their  real-time  deadlines. 


TRANSITION  AND  FUTURE  WORK 

As  part  of  a  tech  transition  activity,  our  Boeing  team  contributed  to  a  research  paper,  entitled 
“Hardware-in-the-Loop  Simulation  Using  Open  Control  Platform,”  written  by  Stanley  Pruett  of 
AFRL/VACD,  Gary  J.  Slutz  of  Protobox,  Jim  Paunicka  of  Boeing,  and  Eric  Portilla  of  NGC. 
The  paper  was  presented  by  Mr.  Stanley  Pruett  of  AFRL/VACD  and  Dr.  James  Paunicka  of  Boe¬ 
ing  at  the  August  2003  AIAA  Modeling  and  Simulation  Technologies  Conference.  The  paper 
and  presentation  covered  topics  including  OCP  and  distributed,  real-time,  HITL  simulations  lev¬ 
eraging  open  systems,  desktop  computing,  and  middleware. 

Immediately  after  this  presentation,  Dr.  Paunicka  was  approached  by  a  representative  of  the  Boe¬ 
ing  Commercial  Airplanes  (BCA)  who  had  attended  the  presentation.  The  BCA  representative 
was  a  simulation  engineer  working  a  number  of  engineering  simulations  for  their  major  product 
lines  (e.g.,  737,  747,  757,  etc.).  These  simulations  at  BCA  are  HITL  (see  Figure  9),  allowing  for 
mix-and-match  avionics  insertion  into  the  simulation  loop.  The  avionics  in  these  simulations 
include  all  pilot  interface  devices  (displays,  lights,  switches,  yoke,  rudder  pedals,  etc.),  naviga¬ 
tion  gear,  flight  computers,  and  other  electronics.  For  each  airplane  product  line,  its  particular 
avionics  are  interfaced  to  multiple  simulation  computers  executing  real-time  operating  systems 
for  activities  such  as  simulation  controllability,  flight  model  execution,  and  instrumentation  data 
logging.  The  simulation  systems  are  used  for  purposes  such  as  new-product  studies,  training, 
investigations,  etc. 
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Figure  9  -  Commercial  Airliner  Cockpit  Simulation 

Dr.  Paunicka  was  invited  to  present  the  OCP  HITL  simulation  work  to  the  BCA  simulation  team. 
This  team  is  considering  a  re-architecture  of  their  multiple  engineering  simulations.  BCA  is  con¬ 
sidering  use  of  middleware  to  enable  rapid  design  of  real-time,  distributed,  HITL  simulations.  In 
addition,  BCA  wants  to  allow  for  isolation  of  simulation  software  from  underlying  compute  plat¬ 
forms  (processor  hardware  and  operating  systems)  for  ease  of  future  upgrades  to  evolving,  up¬ 
dated  compute  platforms.  Ease  of  upgrades  is  important  since  the  7n7  products  that  these  engi¬ 
neering  simulations  support  have  very  long  lifetimes.  This  briefing  was  given  to  the  BCA  team 
at  their  simulation  facilities  building  near  Boeing  Field,  Seattle,  Washington  on  15  December 
2003.  The  BCA  simulation  team  is  still  in  the  process  of  investigating  re-architecture  and  poten¬ 
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tial  use  of  OCP. 


With  the  conclusion  of  this  OCP  HITL  project,  the  AFRL/VACD  lab  now  has  a  capability  for 
distributed  simulation  of  multiple  vehicles,  including  HITL  insertion  of  real-time  flight  software 
executing  on  a  relevant  PowerPC  board  in  a  VME  environment.  The  simulation  is  interfaced  to 
high-value  lab  assets  including  the  Infinity  Cube  displays  and  pilot  input  devices.  Man-in-the- 
loop  operation  has  also  been  demonstrated  and  is  a  capability  available  for  future  use. 

A  flexible  interface  for  sending  multiple  vehicle  data  for  display  on  VBMS  has  also  been  devel¬ 
oped  and  is  available  for  future  use.  This  VBMS  interface,  and  other  simulation  architecture  ar¬ 
tifacts  from  this  effort  were  used  in  a  program  demonstration  on  the  DARPA  High  Confidence 
OCP  program. 

As  part  of  the  design  of  the  final  demonstration,  with  its  multiple-vehicle  configurations,  Boeing 
supported  a  re-design  that  made  it  easier  for  AFRL/VACD  and  for  the  UAV  simulation  model 
and  flight  software  developer,  Northrop  Grumman,  to  quickly  modify  the  number  of  vehicles  in 
the  simulation  environment.  This  involved  creating  an  architecture  not  used  before  which  con¬ 
sisted  of  a  separate  OCP  instance  for  each  simulated  vehicle.  This  multi-OCP  architecture  was 
applied  to  a  distributed  simulation  design  where  major  UAV  processes  were  distributed  among 
multiple  computers,  most  of  which  were  not  running  real-time  operating  systems.  This  distrib¬ 
uted  architecture  appeared  to  exhibit  near  real-time  performance,  although  intensive  investiga¬ 
tions  by  AFRL/VACD  personnel  revealed  that  real-time  operation  of  all  vehicle  instances,  and 
time  synchronization  among  all  vehicle  simulations,  was  not  perfect.  Future  work  could  improve 
on  the  design  and  synchronization  of  these  multi-OCP  instantiations  applied  to  multi-vehicle, 
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real-time  simulations. 


CONCLUSIONS 


The  OCP  has  been  shown  to  be  an  enabler  for  rapid  design  of  distributed,  HITL  simulation. 
Software  developed  by  three  different  teams  is  being  integrated  with  little  difficulty  due  to  the 
well-defined  OCP  interfaces,  demonstrating  that  OCP  can  be  used  also  for  efficient  multi¬ 
organization,  parallel  software  development.  The  ownship  controller  process  that  was  developed 
and  tested  on  a  Win2k  machine  was  easily  ported  to  a  YxWorks  machine.  The  current  HITL 
simulation  is  successfully  running  on  a  heterogeneous  network  of  machines. 

Testing  of  the  2-ship  non-co-operating,  the  2-ship  co-operating,  and  the  pilot- in-the-loop  scenar¬ 
ios  occurred  May  2003.  Testing  of  the  formation  flight  and  fault  injection  scenarios  is  scheduled 
for  May  2004. 
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